Method and apparatus for extracting digital data from a medium

ABSTRACT

A computer-implemented method and apparatus for extracting digital data from a medium. Digital audio extraction techniques are implemented with additional features that improve the quality of the resulting audio playback files. In one embodiment of the invention, a user can extract digital audio data from a source medium and store the data as a file or, alternatively, stream the data into a memory. The file/stream can then be analyzed to determine the precise locations, in time, at which the sound levels represented by the data cross a specified threshold, particularly at locations near and between track edges. This information can be stored for reference. Subsequently, the file/stream can be accurately divided into smaller files wherein each file contains one or more complete and distinct tracks, and the data representing sound levels below the specified threshold can be excluded from the resulting files. The files may then be encoded and/or further divided into standard playback files. Another embodiment of the invention includes an audio player. The player can play the playback files, in their original order, and can automatically include sections of silence between tracks, where required, and will refrain from including sections of silence or pauses between tracks that are intended to be played end-to-end.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/991,088, filed Nov. 13, 2001, now U.S. Pat. No. 7,161,887, for“Method and Apparatus for Extracting Digital Data from a Medium,” whichis incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The invention relates generally to the field of data extraction andencoding, and more particularly to an improved system and method ofextracting digital audio data from a medium to one or more playablefiles.

BACKGROUND OF THE INVENTION

Digital Audio Extraction (“DAE”), also known generally as “ripping,” isthe process of copying a track from an audio disc, usually music, to ahard drive or other storage medium by creating a file (or group offiles) in any number of encoded and/or compressed formats (e.g., WAV,MP3, . . . etc). A wide variety of software packages that utilize DAEare now available, and the average computer user can easily “rip” anynumber of tracks from a CD collection to one or more files on a computerhard drive. Subsequently, these tracks can be played back with softwaredesigned to read and play extracted audio files.

Although ripping has become a common practice for many computer users,high quality audio extraction can be difficult because of thecomplexities inherent in the way data are stored on audio discs. AudioCD data are organized into sectors in order to ensure a constant readrate. Each sector consists of 2,352 bytes of sound data along withsynchronization, error correction, and control/display bits. Thesesectors are further broken down into sound samples. Each sector contains588 samples of sound for each of two stereo channels, and each samplecontains two bytes (16 bits) of sound data. The standard sampling rateof CD players is 44,100 samples per second.

Sectors are not arranged in distinct physical units. Instead, the datain one sector are interleaved with data in other sectors so that adefect in the disc will not destroy a single sector beyond correction.In addition, each track's location, or address, is recorded in thedisc's Table of Contents (“TOC”), which is stored in the “lead in” areaof every disc. Accordingly, an audio disc's TOC, much like a book's, isa good resource for determining where tracks begin and end. The TOCindicates the minute, second, and sector (to 1/75^(th) of a second) atwhich each track begins.

Extraction of audio/video content from a compact disc to a hard diskusing current DAE software can be a difficult task. Every byte of a2,352-byte sector of audio data is used strictly for audio. Essentially,no header exists; there is no information in the sector that allows forthe exact positioning of a read head over a specific sector. To addressan audio sector, a CD-ROM drive uses the TOC data to approximate how farout along the CD it must scan in order to find the beginning of aspecified track. Drives typically reach an audio address that is within± four sector addresses of the address being sought (± 4/75^(th) of asecond in playback time), and a read request may return any one of thenine sectors. This inexact positioning may cause undesired clicks andpops, commonly referred to as “jitter,” in extracted audio files.

Graph 110 of FIG. 1 is a plot (not to scale) of the audio level (e.g.,audio volume, audio intensity, audio amplitude . . . etc) of an audiorecording 120 overtime (horizontal axis). Track divisions 130 representwhere tracks (e.g., songs, of audio recording 120) begin and end.Threshold 140 represents a predetermined level threshold and lines 150represent the points at which the sound level of audio recording 120drops above or below threshold 140. For example, the level of audiorecording 120 is below threshold 140 during time lapses 152 and 154.Time lapses 152 and 154 represent the dead silence that may exist at thebeginnings and ends of songs on a CD, respectively. Lines 160 representthe points at which the sound level of audio recording 120 significantlydrops but does not drop below threshold 140. For example, the level ofaudio recording 120 is dropped significantly during time lapse 164. Timelapse 164 represent a lull in the level of audio recording 120 that mayoccur between tracks, such as clapping in between songs of a live album.Finally, it is shown that a lull in the level of audio recording 120does not exist in between tracks 3 and 4. This is an example of twotracks that blend into each other during playback without any lull insound level.

Current DAE software can be used to extract audio recording 120, andFIG. 2 shows how current DAE programs function. A current DAE programwill extract each track of audio recording 120 separately and create apulse-code-modulation (PCM) file for each track (PCM files 201-204).These PCM files can eventually be converted to encoded file formats(encoded files 211-214) that may be read for playback of audio recording120. These encoded file formats may be uncompressed or compressed (e.g.,via MP3 or WAV file formats).

One disadvantage to current extraction techniques is that the softwareextracts each track from the source CD separately. First the softwarewill read the CD TOC to determine the locations of the tracks to beextracted. Then each track will be extracted from a beginning point thatmay or may not be where the track actually starts and will endextraction at a point that may or may not be where the track actuallyends. Again, the read head's accuracy in finding sector addresses islow, and it can only approximately find the start of a track. Giventhese uncertainties, one or more sectors of a track may be lost duringextraction, or one or more sectors may be unintentionally added. Forexample, FIG. 3 illustrates some of the drawbacks of using DAEtechniques currently known in the art. Audio track 310, beginning attime 302 and ending at time 304, can be extracted from an audio CD. Theresulting PCM (pulse-code modulation) data file may contain missingsectors (e.g., PCM file 320), extra sectors (e.g., PCM file 330), orboth missing and extra sectors (e.g., PCM file 340) at either or bothends of the file. This problem is further exacerbated when a filecontains extra sectors that overlap with sectors contained in aconsecutive track (e.g., overlapping sector 360 of PCM file 350).Overlapping sectors will cause increased jitter when extracted tracksare played back in their original order. Jitter is particularlynoticeable between extracted tracks that are intended to blend into eachother during playback (e.g., a segway, a house mix, or a liverecording). These types of recordings may not have the same dead silencebetween tracks that typical multi-track recordings have.

The problems described above are caused because current DAE programs donot analyze the bridges between tracks to determine if there exists deadsilence or just a lull in the sound, as in a live recording. Instead,current programs simply add a small amount of silence between extractedtracks during playback even though that silence may be undesirable forcertain track sets. Finally, if there is some noticeable sound betweentracks, there is a clear loss of sound quality during playback becausecurrent DAE techniques cannot adequately compensate for jitter.

SUMMARY OF THE INVENTION

A computer-implemented method of extracting digital audio data isdescribed comprising: reading digital audio data from a medium;analyzing the digital audio data to determine when the levels of audiosound contained therein cross specified thresholds over time; anddividing the digital audio data into files that each contain one or morecomplete tracks and exclude data representing sound levels below aspecified threshold.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained from thefollowing detailed description in conjunction with the followingdrawings, in which:

FIG. 1 illustrates a graph of an exemplary audio recording includingsound levels plotted over time.

FIG. 2 illustrates a method by which digital audio extraction is used inthe current art.

FIG. 3 illustrates some of the drawbacks in using current digital audioextraction techniques including some of the causes of jitter.

FIG. 4 illustrates one embodiment of the digital audio data extractionprocess, wherein audio data is extracted, segmented, encoded and sliced.

FIG. 5 illustrates a flow diagram of one embodiment of the digital audiodata extraction process.

FIG. 6 illustrates a flow diagram of another embodiment of the digitalaudio data extraction process.

FIG. 7 illustrates s CD/DVD storage and playback system as it is used inconjunction with one embodiment of the invention.

FIG. 8 illustrates one embodiment of a system for reading, slicing,encoding and splitting multimedia content.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however, toone skilled in the art that the present invention may be practicedwithout some of these specific details. In other instances, well-knownstructures and devices are shown in block diagram form to avoidobscuring the underlying principles of the present invention.

The process of digital audio extraction first requires a source mediumthat contains digital audio data. The source medium can be one of avariety of plastic disc forms (e.g., CDs, MiniDiscs, DVDs) or magneticdisk forms (e.g., floppy or hard disks). The audio data contained on thesource medium is arranged in a format, e.g., pulse code modulation (PCM)format, that can be read by a standard audio player such as CD player.In addition, the audio data is typically divided into tracks, where eachtrack represents a distinct block of audio data such as a song. Sourcemediums can contain a multitude of tracks and additional data thatindicate the start of each track relative to the data in minutes,seconds, and sectors. For example, the Table of Contents (“TOC”) of a CDcontains data that indicate to a CD player the points at which CD tracksbegin.

FIG. 4 shows graph 110 which is also depicted in FIGS. 1 and 2. Again,graph 110 is a plot (not to scale) of the sound level (vertical axis) ofaudio recording 120 over time (horizontal axis). Track divisions 130represent where tracks, e.g., songs, of audio recording 120 begin andend. Threshold 140 represents a predetermined level threshold and lines150 represent the points at which the sound level of audio recording 120drops above or below threshold 140. For example, the level of audiorecording 120 is below threshold 140 during time lapse 440, 442, and448. Time lapses 440, 442, and 448 represent the dead silence that mayexist at the beginnings and ends of songs on a CD, respectively. Lines160 represent the points at which the sound level of audio recording 120significantly drops but does not drop below threshold 140. For example,the level of audio recording 120 is dropped significantly during timelapse 444. Time lapse 444 represents a lull in the level of audiorecording 120 in between tracks, such as clapping in between songs of alive album. Finally, it is shown that a lull in the level of audiorecording 120 does not exist in between tracks 3 and 4. This is anexample of two tracks that blend into each other during playback withoutany lull in sound level.

FIG. 5 shows a flow diagram of the steps taken by one embodiment of theinvention to extract, analyze, and store digital audio data. It willappreciated by those skilled in the art that the steps diagramed in bothFIGS. 5 and 6 may followed in the indicated order or in a differentorder while achieving many of the same benefits of the presentinvention. In addition, certain steps may be skipped and/or alternatesteps may be employed while complying with the underlying principles ofthe invention.

At block 510 the raw audio data contained on the source medium is readby a computer device such as a CD-ROM, and at block 520 the raw data isstored as raw file 420 in an addressable memory space such as a harddrive or RAM. In one embodiment, rather than storing the raw data as a“file” at 420, the raw data may be streamed from the CD to anapplication which operates on the data stream as described herein. If aCD is being ripped, this file/stream 420 contains PCM data that includesaudio data and possibly additional data (e.g., TOC data) used to addressspecific locations within the PCM data. It will be understood that theTOC data read from the source medium can be stored as part of rawfile/stream 420 or as a separate file (e.g., TOC file 524).

Audio recording 120 of FIG. 4 is an exemplary plot of the sound levelsproduced when the audio data of raw file/stream 420 are played. At block530, of FIG. 5, raw file/stream 420 is analyzed to determine the pointsat which the sound level of audio recording 120 drops below threshold140. Threshold 140 may be set at a sound level comparable to thethreshold of human hearing. In one embodiment, each point analyzed isequivalent to a sound sample (e.g., two bytes of data for each channel),which will represent some amplitude of sound. One embodiment of theinvention locates these points using the TOC data stored in rawfile/stream 420. The TOC data will indicate at which minute, second, andsector each track of the raw audio data (or other types of multimediadata) begins. For example, track edge 430 includes an addressrepresenting where track two begins. Once these locations are known,samples of audio data located at predetermined distances behind and/orahead of, relative to time, each track edge is analyzed to determine ifthe indicated sound levels are above or below threshold 140. Forexample, it will be determined that the data sectors located across timelapse 442 contain sound levels below threshold 140. The data sectorsmarking the locations where the indicated sound levels cross threshold140 may be stored in an index file, e.g., index file 535. In addition,if there exists no data sectors that indicate sound levels belowthreshold 140 in the vicinity of a track edge, then that information isstored as well.

Once the raw file/stream 420 (or the streamed content) has beencompletely analyzed, moving onto block 540, one embodiment of theinvention divides raw file/stream 420 into smaller chunks or segments ofdata. This division will occur at every track edge except at those edgeswhere sound levels are maintained above threshold 140. For example, asegment division will occur at track edge 430 but not at track edge 432or 434. This is because the sound levels represented by time lapse 442drop below threshold 140 and the sound levels represented by time lapses444 and 446 are maintained above threshold 140. Sections of audio datathat contain sound levels below threshold 140 will be referred to hereinas “silent” sections. During or subsequent to the division of rawfile/stream 420 (see block 540), the silent sections, represented bytime lapses 440, 442 and 448, will be excluded from the resultingsegments. Accordingly, segments 450 and 455 are generated and theircorresponding shorter lengths are shown in FIG. 4. In one embodiment,segments 450 and 455 are merely two smaller files similar or identicalin format to raw file/stream 420. In addition, while segment 450contains only track 1, segment 455 contains tracks 2, 3, and 4. It willbe appreciated by one skilled in the art that excluding sections of datathat do not benefit the end user, e.g., silent sections, will beadvantageous for a variety of reasons. For example, there will be lessdata to encode, the resulting files will be smaller in size, and themultimedia content stored within the files will start and end moreprecisely.

Depending on the number tracks and silent sections contained in rawfile/stream 420, a multitude of segments may result after the divisionat block 540 of FIG. 5. Again, each of the segments can contain one ormore tracks, and if one segment contains more than one track the soundlevels produced at the track edges are high enough to be heard by an enduser. At block 550, segments 450 and 455 are encoded to a data formatthat may be read by a standard digital audio player. For example,segments 450 and 455 may be encoded to a WAV file format or they may beencoded and compressed to an MP3 file format such that a standard MP3player may read and play them. It will be understood that the encodingstep of block 550 may occur before the segmenting step of block 540 orbefore the analyzing step of block 530 without losing the inventivefeatures described herein. In addition, it will be appreciated that anynumber of segments produced at block 540 may be encoded and a variety ofencoded formats may result following block 550. As shown in FIG. 4,segment 450 is encoded to playback file 460 and segment 455 is encodedto multi-track playback file 465. It will be understood that the size ofthese files will be different after encoding and/or compression takesplace, but the resulting length of each segment, in time, will bepreserved during playback. Either playback file 460 or 465 may be playedby a standard digital audio player; however, a user may desire to storeone of the three tracks contained on multi-track playback file 465separately or insert one of the three tracks into a differentarrangement of tracks. Therefore, at block 560, multi-track playbackfiles are split such that a separate file is created for each distincttrack.

One embodiment of the invention contains a file slicer that can divideone or more encoded files into their separate tracks. The file slicercan separate two or more tracks from a multi-track playback file suchthat no pertinent data are lost. This is accomplished with the help ofthe TOC data found in either TOC file 524 or raw file/stream 420,depending on where the TOC data were stored at block 520. The sliceruses the TOC data to find the precise sector(s) at which each track ofplayback file 465 begins. Then the slicer divides the playback file intosmaller playback files, wherein each smaller playback file will containa complete and distinct track. The slicer extracts all the correspondinggroups of sectors of data that are representative of each track and thenstores each extracted group as a smaller playback file. Therefore, nosectors are lost. For example, playback file 465 of FIG. 4 can be slicedinto smaller playback files 472, 474 and 476. Each of the smallerplayback files contains a complete and distinct track. These smallerplayback files may be played separately or in sequence without anynoticeable loss of sound quality during the time a player is switchingbetween tracks.

It will be understood that the track addresses indicated by the TOC dataare only compatible with the raw audio data stored in PCM format. Onceencoding occurs the format of the audio data will change and the numberand arrangement of sectors in the encoded data file may also change.However, one embodiment of the invention will anticipate this change andcovert the address given by the TOC data to an address that iscompatible with the encoded data format.

One embodiment of the present invention also includes an audio player.This audio player is capable of reading a variety of encoded fileformats including those uncompressed and compressed. The audio playercan playback the files generated by block 550 or 560 of the extractionprocess. One advantage of the audio player is that it can recognizetracks that are generated from a multi-track segment. For example,playback files 472, 474 and 476 are three separate tracks originatingfrom segment 455. These tracks are unique because no sections of silenceexist in between any two contiguous tracks. This is common for audiorecordings that contain tracks that blend into each other, without anypauses of silence, or off a live album where a listener can still hearthe sounds of the band and audience between songs. Therefore, it isadvantageous to playback these tracks in their original order withoutany undesired silence or jitter. With reference to index file 535, theaudio player can determine if two or more tracks are intended to beplayed end-to-end without a pause of silence, and, if so, the playermoves from playing one track to the next without a pause or noticeableloss of sound quality. Furthermore, if a pause of silence is meant toexist between two contiguous tracks (e.g., between tracks 1 and 2 ofFIG. 4), the player can reference index file 535 to determine exactlyhow long the pause of silence was in the original recording and canreinsert that amount of silence in between the tracks currently beingplayed.

As seen in FIG. 6, a variation of the audio data extraction processdescribed above may be executed while achieving the same benefits of thepresent invention. The steps represented by blocks 610, 620 and 630 areidentical to those of blocks 510, 520 and 530, respectively. However, atblock 640, the raw audio data is not broken up into segments, but israther encoded into a large playback file, e.g., playback file 645. Itwill be understood that playback file 645 may contain all or less thanall of the tracks found on raw data file 420. A player, in anotherembodiment of the invention, may playback any number of tracks off ofplayback file 645, in any sequence, and can use the information storedin index 535 to determine the exact positions to begin and end playbacksuch that there is no noticeable loss in sound quality.

In FIG. 7 a CD/DVD storage and playback system 700 is illustrated inanother embodiment of the invention. The system 700 includes a storageand playback apparatus 705 which communicates over a network 740 to oneor more servers 750. The steps represented by FIG. 5 or FIG. 6 may beembodied in program code stored on storage device 730 of playbackapparatus 705 and may be loaded into memory 715 and executed by amicroprocessor 710 contained therein. Playback apparatus 705 may be astand-alone terminal or a client terminal connected with a network,e.g., network 740, further connected with one or more servers, e.g.,server 750, via network interface card 720.

In one embodiment, a user loads each of his or her CDs into playbackapparatus 705 and all of the digital audio data contained on each CD isextracted and stored into separate raw data files on storage device 730.Each raw data file may be segmented, encoded, and sliced given themethods described above. Ultimately, playback files containingindividual tracks are generated, and the user may playback such files onthe playback apparatus 705. The playback apparatus 705 may also includeuser display 760 which can display information relevant to a selectedtrack. For example, user display 760 may display the artist name, albumtitle, song title, track number (relative to a track set) and albumrelease date. It will be appreciated that this CD-related informationmay be retrieved from data stored on the CD, from manual user input, orfrom a database found on a server 750.

In one embodiment, the techniques described herein may be implemented ona specialized multi-CD ripper apparatus such as that described inco-pending application entitled “MULTIMEDIA TRANSFER SYSTEM” (Ser. No.09/717,458) which is assigned to the assignee of the present applicationand which is incorporated herein by reference. For example, using thissystem, content from multiple CDs may be concurrently processed andstored on a user's playback apparatus 705 in the manner described above.

One specific embodiment of a system for reading, slicing, encoding andsplitting multimedia content as described herein is illustrated in FIG.8. The system is illustrated as a plurality of modules which may beembodied in hardware, software, or any combination thereof. Asillustrated, the multimedia content 810 is initially streamed from a CD820 (or other medium) into memory by a media ripper module 830. Thesound levels of the raw streamed content are then analyzed by a waveslicer module 840 which separates the raw stream data into segmentsbased on its analysis (e.g., using the techniques described above).Index data, TOC data and/or other types of multimedia-related data mayalso be processed by the media ripper module 830 and the wave slicermodule 840 during the foregoing processing stages. One or moremultimedia encoder modules 850 then encode each of the multimediasegments using a particular encoding algorithm (e.g., MP3, AC-3, . . .etc, for audio; MPEG-2, MPEG-4, RealVideo 8, . . . etc, for Video). Onceencoded, each individual segment may then be logically divided by asplitter module 860 as described above. For example, if the rawmultimedia data is audio data, the splitter module 860 may divide theencoded audio segments into a plurality of distinct MP-3 files. Aspreviously mentioned, audio encoding may occur before or after audiosegment splitting, depending on the embodiment.

Embodiments of the present invention include various steps, which weredescribed above. The steps may be embodied in machine-executableinstructions. The instructions can be used to cause a general-purpose orspecial-purpose processor to perform certain steps. Alternatively, thesesteps may be performed by specific hardware components that containhardwired logic for performing the steps, or by any combination ofprogrammed computer components and custom hardware components.

Elements of the present invention may also be provided as amachine-readable medium for storing the machine-executable instructions.The machine-readable medium may include, but is not limited to, floppydiskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs,RAMs, EPROMs, EEPROMs, magnet or optical cards, propagation media orother type of media/machine-readable medium suitable for storingelectronic instructions. For example, the present invention may bedownloaded as a computer program which may be transferred from a remotecomputer (e.g., a server) to a requesting computer (e.g., a client) byway of data signals embodied in a carrier wave or other propagationmedium via a communication link (e.g., a modem or network connection).

Throughout the foregoing description, for the purposes of explanation,numerous specific details were set forth in order to provide a thoroughunderstanding of the present system. It will be apparent, however, toone skilled in the art, that the system and method may be practicedwithout some of these specific details. For example, while thetechniques described above were employed in the context of ripping audiofrom CDs, the same techniques may be employed using a variety ofdifferent media (e.g., DVD audio/video). Accordingly, the scope andspirit of the invention should be judged in terms of the claims whichfollow.

1. A computer-implemented method comprising: reading digital audio datafrom a source medium, the digital audio data divided into a plurality oftracks, each track representing a discrete chunk of digital audio dataand having sound levels varying as a function of a variable; analyzingthe digital audio data to determine the levels of sound as a function ofthe variable and determining one or more precise values of the variableat which the level of sound crosses a specified threshold; and dividingthe digital audio data into a plurality of separate files, each filecontaining one or more tracks and each file excluding the digital audiodata having levels of sound below the specified threshold, wherein thesource medium contains Table of Contents (“TOC”) data identifying thevalues of the variable at which each track begins and ends within eachfile and within each segment, said method further comprising reading andstoring the TOC data, and wherein dividing includes: if the level ofsound at a point where a first track ends and a second track begins isnot below the specified threshold, then including the first and secondtracks in the same file; and if the level of sound at a point where athird track ends and a fourth track begins is below the specifiedthreshold, then including the third and fourth tracks in separate files.2. The method of claim 1 further comprising: encoding at least one ofthe files to generate a playback file that may be read by an audioplayer.
 3. The method of claim 2 wherein the encoding includescompressing the digital audio data contained on the file.
 4. The methodof claim 2 further comprising: if a playback file contains two or moretracks then, with reference to the TOC data, dividing the playback fileinto smaller playback files such that each smaller playback filerepresents a discrete track, and two or more of the smaller playbackfiles may be played consecutively without a pause or loss in soundquality during the time an audio player is switching between playingcontiguous tracks.
 5. The method of claim 2 further comprising: if afirst file is contiguous to a second file, determining an amount of timeequal to the digital audio data that was excluded, during said dividing,from between the first and second files; and storing the amount of timeand its position relative to the one or more files; and insertingsilence for a time equal in length to said amount time after an audioplayer's playback of the one or more tracks contained in the first fileand prior to an audio player's playback of the one or more trackscontained in the second file.
 6. The method of claim 3 wherein thecompressing comprises MP3 compression.
 7. The method of claim 3 whereinthe compressing comprises AC-3 compression.
 8. The method of claim 1wherein the variable is time.
 9. The method of claim 1 wherein thevariable is a number of data sectors.
 10. The method of claim 1 whereinthe source medium is a compact disc (“CD”).
 11. The method of claim 1wherein the source medium is a mini-disc.
 12. The method of claim 1wherein the source medium is a digital video disc (“DVD”).
 13. Themethod of claim 1 wherein the file is a chunk of contiguous digitalaudio data.
 14. The method of claim 1 wherein the audio data is PCMdata.
 15. A machine readable medium including program code which, whenexecuted by a machine, causes said machine to: read digital audio datafrom a source medium, the digital audio data divided into a plurality oftracks, each representing a discrete chunk of digital audio data andhaving sound levels varying as a function of a variable; analyze thedigital audio data to determine the levels of sound as a function of thevariable and determining one or more precise values of the variable atwhich the level of sound crosses a specified threshold; and divide thedigital audio data into a plurality of files, each file containing oneor more tracks and each file excluding the digital audio data havinglevels of sound below the specified threshold, wherein the source mediumcontains Table of Contents (“TOC”) data identifying the values of thevariable at which each track begins and ends within each file, andwherein the digital audio data is divided according to the followingsteps: if the level of sound at a point where a first track ends and asecond track begins is not below the specified threshold, then includingthe first and second tracks in the same file; and if the level of soundat a point where a third track ends and a fourth track begins is belowthe specified threshold, then including the third and fourth tracks inseparate files.
 16. The machine readable medium of claim 15 furthercausing said machine to: encode at least one of the files to generate aplayback file that may be read by an audio player.
 17. The method ofclaim 16 wherein the encoding includes compressing the digital audiodata contained on the file.
 18. The machine readable medium of claim 16further causing said machine to: if a playback file contains two or moretracks then, with reference to the TOC data, divide the playback fileinto smaller playback files such that each smaller playback filerepresents a discrete track, and two or more of the smaller playbackfiles may be played consecutively without a pause or loss in soundquality during the time an audio player is switching between playingcontiguous tracks.
 19. The machine readable medium of claim 16 furthercausing said machine to: determine, wherein a first file is contiguousto a second file, an amount of time equal to the digital audio data thatwas excluded between the first and second files; store the amount oftime and its position relative to the one or more files; and insertsilence for a time equal in length to said amount time after an audioplayer's playback of the one or more tracks contained in the first fileand prior to an audio player's playback of the one or more trackscontained in the second file.
 20. A computer-implemented methodcomprising: reading digital audio data from a source medium, the digitalaudio data divided into a plurality of tracks and having sound levelschanging over time; analyzing the digital audio data to determine thelevels of sound as a function of time and determining one or more pointsin time at which the level of sound is below a specified threshold; anddividing the digital audio data into a plurality of distinct files, eachfile containing one or more of said tracks and each file excluding thedigital audio data having levels of sound below the specified threshold,wherein the source medium contains Table of Contents (“TOC”) dataidentifying the time at which each track begins and ends within eachfile and within each segment, said method further comprising reading andstoring the TOC data, and wherein dividing includes: if the level ofsound at a point where a first track ends and a second track begins isnot below the specified threshold, then including the first and secondtracks in the same file; and if the level of sound at a point where athird track ends and a fourth track begins is below the specifiedthreshold, then including the third and fourth tracks in separate files.21. The method of claim 20 further comprising: encoding one or more ofthe files to generate a playback file that may be read by an audioplayer.